Blogs

Last time, I talked about the recent SharePoint conference and some of the ECM gaps that have been carried forward into the soon-to-be-released 2013 version of SharePoint.

This week I will focus on metadata and share some of my best practices for the use of metadata in ECM systems like SharePoint. You will find most of these recommendations apply equally to any ECM implementation whether you’re using SharePoint or not, and that’s an important point. Although SharePoint is often seen as a transformational platform, its core functionality is not that different from most ECM platforms. Although there are some quirks in SharePoint, most of the advice I will offer can be applied to out-of-the-box SharePoint or any other ECM platform.

Think globally, act locally

This advice borrowed from the environmental movement applies to many aspects of an ECM implementation and is especially helpful when working with metadata. Sadly, we do not live in a perfect world and most implementations do not have the luxury of coming up with a perfect enterprise-wide metadata hierarchy. Especially when dealing with SharePoint, metadata structures tend to evolve from departmental needs rather than from a centrally-planned master list. There is nothing inherently wrong with this; after all, our job is to solve business problems. However, when several departments come up with their own structures it can be a problem because several terms can be used to describe the same thing.

I encourage my clients to establish a thin layer of standardization across the enterprise, perhaps starting with a top-level metadata values like Business Function and Document Type. In most situations I encourage them to create a hierarchical relationship to increase relevance and reduce the opportunity for error when applying the Document Type value. From here departments can choose metadata values that speak to their specific business needs, perhaps including things like Client Name or geographic values.

The list of business-specific metadata lists is as long as your organization is large but it is critical to try to re-use existing metadata fields wherever possible. In SharePoint, this means using the Managed Metadata features that first appeared in the 2010 version. The finer points of Managed Metadata in SharePoint is a blog post (or two) unto itself so I’ll refer you to an excellent summary of metadata in SharePoint by UK-based SharePoint MVP Chris O’Brien.

How much is enough? How much is too much?

This is the age-old question when it comes to metadata. On one hand, it is important to provide enough information to be able to retrieve documents but at the same time we need to be careful about overwhelming our users. If we’re not careful, everything will end up with a Business Function of ‘Administration’ and a Document Type of ‘Agenda’, simply because those are the first two items in each list.

My advice is to ask your user community to add no more than one or two metadata tags to each document. Where there are more than two fields you will very likely be able to use inheritance to pre-populate one or more of these. For example, in a library called ‘Contracts’ located in a SharePoint site for the US Midwest sales team, you can pre-populate the Business Function ‘Legal’, the Country ‘US’, Region ‘Midwest’ and Activity ‘Sales’ while only asking your users to select which type of contract they are entering and perhaps selecting a value in the Client field.  In my experience users respond well to this model; they get six metadata values without doing a lot more work than they would in a traditional File / Save As… scenario.

You might be wondering why I haven’t included date values like Effective Date and Expiry date in the list above. I certainly could have, and this is a valid use of an ECM system. However, it is likely that you already have a contract management system in place and including such information in SharePoint is extraneous and could potentially lead to confusion. There is no single right answer because these types of decisions differ for each organization. As I will discuss below, integration with line-of-business systems is one way to address this question.

A single source of the truth

Consistent with the ‘Enterprise’ part of Enterprise Content Management it is important to leverage existing master data lists and structures wherever possible. In our example above users should not be allowed to enter their own values in any of our metadata fields. If we enter into a contract with Acme Brush Corp, you could easily see values of ‘Acme’, ‘ABC’, ‘Acme Brush’ or any number of other combinations in a free-text Client field. I don’t need to tell you this defeats the purpose of a managed metadata structure. The best-case scenario is to integrate your ECM system with an existing master metadata list from another line-of-business system. This has the added benefit of enabling easier integration between these systems because you now have the option of document-enabling many line-of-business systems by allowing those systems to query your ECM application rather than storing copies of documents in multiple systems.

I'm sure you'll agree most this advice applies equally to any system, which is really the point. Although SharePoint has its shortcomings when managing metadata, most business needs can be met thorough out-of-the-box functionality. As with most questions in the exciting world of information management, taking a systematic approach to solving a business problem is the best way to ensure a good outcome.