SharePoint – Adding ECM Structure

While majority of the work we do is Documentum or Alfresco related, we recently had the opportunity to help a client re-structure their SharePoint implementation. They are a small company that adopted SharePoint several years ago, however, they were unhappy with how the system was being used (or in essence not being used). Each user had individual control over what and how they stored documents in SharePoint therefore treating the system as a glorified file share. It was unclear what content existed, how many versions (or copies) of it existed and in short, very challenging for anyone other than the owner of the document to find anything.

While SharePoint typically isn’t our specialty, the principles behind content management are. We used our experience in this area to implement basic SharePoint configurations in order to have better control over their content. First we worked with the client to define an enterprise taxonomy which included the following steps:

  1. Define the main business processes in company.
  2. For each business process, define what types of documents they create.
  3. For each document type, define what key data points they want to capture.
  4. For each data point, define possible values.

This structure enforces that “like” documents are stored together as well as have the same definition through site columns and fixed lists of values. The end result makes it easier for users to find documents through search or navigation as well as mitigates the risk of duplicate work.  These changes provide users intuitive means to find documents rather than the legacy method which consisted of calling someone, recreating it or hunting and picking in the system.

This structure was then used to configure process driven document libraries and search screens. Within the libraries we were able to leverage the required site columns to define document views in order to provide optional means of looking for documents. Since we removed the ability to bury documents in a folder structure, this configuration provides users the ability to create “virtual” folders that are meaningful to them.

By restructuring documents by process rather than department, it also allows for change in the future. As new processes are added or even changed, they can easily be added to the current configuration. Additionally, if departments are restructured, it has no impact on the way the documents are organized.

The biggest challenge for this project was taking the current list of documents (upwards of 50,000) and determining where they fit in the new taxonomy. Since they were coming from an unstructured system, there was no easy way to automate this process – user’s had to manually determine where a document belonged in the new structure. This tedious task could have easily been rushed or eliminated from the project; however the client made it a priority for a few reasons:

  1. SharePoint Cleanup – Since the old system was unstructured, there were a lot of documents that could be archived or deleted. Identifying these documents before migration cut the total count in half.
  2. Prove out the New Taxonomy – While the project team spent a lot of time defining the new structure, it was hard to prove that all aspects were considered. By determining where existing content belonged in the new structure, holes in the taxonomy were identified and accounted for prior to the system going live. This is where the ease and flexibility of configuring SharePoint worked in our favor. We could easily respond to changes in the system which I think will be a plus as the new process grows.
  3. Train Users – One of the best ways to learn and retain something is through repetition. The users assigned to tag existing documents had plenty of practice and exposure to the new structure. The idea is they can now take what they learned and be process champions to those not as exposed to the project. The user buy-in is critical for change management acceptance and adoption.

The users did a great job tagging all documents which then allowed us to migrate about 25,000 documents into the new structure. The process driven SharePoint has now been in place for over a month and the feedback has been positive.

3 thoughts on “SharePoint – Adding ECM Structure

  1. Functional taxonomy is usually better than organisational (in my opinion too)

    However, in large organisations – a hybrid approach is usually more popular

    Division based taxonomy – then – Functional taxonomy

    … as there are fewer processes that span across divisions compared to processes that pertain to the departments of busines units of a division

    happy to hear what others think


Comments are closed.