SharePoint 2010′s ability to store metadata is being touted as one reason that it is now a viable platform for enterprise content management. Yet according to AIIM’s 2011 report: “Using SharePoint for ECM,” only 8% of survey respondents have completed their upgrade to 2010.
When asked, “What were the biggest issues for you in upgrading to SharePoint 2010?” The number one issue cited was “Standardizing on taxonomy or metadata template.”
This challenge I believe fits the old adage, the longest journey starts with a single step. Every company has metadata and contextual information stored in older versions of content management systems, legacy applications like Lotus Notes, or on individual desktops. The collective knowledge, vocabulary and metadata of the organization sits in those repositories. Like nuggets of gold, they must be mined and culled from legacy systems and redundant, outdated and trivial terms must be discarded and appropriate ones put to use in SharePoint 2010.
All content, including documents are tied to business process transactions, it is not the name of the document that defines it, but its role in a business process. For instance, a “contract” for Piggly Wigglgy in a sales process triggers different functions, process and activities in the legal department post signature. It is the same content, but increases in complexity based on business trigger events that include additional content and metadata e.g. modification of standard terms.
To explain, I will borrow what Rahel Baillie defines as the “content asset amplification” effect. Rahel describes this as the transformation of an “information transaction.” Rahel goes on, “An Information transaction is comprised of a sum of 1 to n sets of content artifacts including modules, style sheets, audiences, data, graphics and potentially multiple others” It looks like this: 
Could this formula be the baseline for common metadata standard? I think so, Rahel describes the basis of the formula as a “information transaction.” Because transactions involve an information or document exchange, it is not the name of the document that defines it, but the role in the business process. In the case of the sales contract, who else had input? Did delivery add special terms? Did accounts receivable have input on payment terms? What wording or concessions did legal approve? Each input adds another layer to the document.
Sales Contract modification Case Study
This is an example of a recent contract negotiation that required modification of deliverables and terms on a sales contract.
Client requirements:
- Modification of standard delivery process from offsite to 50% onsite. Approval required: Delivery, T&E and Legal. Wording required: Delivery (P1) and Legal (P2).
- Modification to indemnification clause. Approval required: Legal. Wording required: Legal
- Modification of payment terms from 50% on signing to milestone payments. Approval required: CFO and Delivery. Wording Required: AR (P3)
I am going to highlight both examples that touch on the legal department. A taxonomy allows the chief council and staff to have content components of “contract terms – delivery” and “contract terms – indemnification” for reuse. Without a taxonomy, the reuse and findability would be based on manual search or worse yet someone remembering where similar terms were used in the past. Assigning Processes to Rahel’s Asset Amplification the equation now looks like this:
Although this equation looks complicated, it is actually quite natural, and is a representation of how existing business documents flow within your organization. As information flows from process to process for input, it dynamically adds complexity to content and metadata. Corporate standards are then applied to allow for the dynamic syncing and presentment of content from business process to process.
So where do you start? This is up for debate, if you went to the doctor and said, “I don’t feel well,” they will come back with “where does it hurt?” Trite I know, but there is no standard starting place. Today’s options for taxonomy and metadata creation are:
- purchase an off the shelf taxonomy specific to your industry or business function
- manually create a taxonomy from the ground up
- use an automated creation by using a tool for element discovery and extraction
- combinations of the above
If you are working with the type of people who need to be shown something, bring in technology and present the metadata in a hierarchical list to a group for refinement. If user adoption is paramount, you may want to pull people into a room for a facilitated card sorting exercise. SharePoint taxonomy expert @mikedoane shared his methodology for taxonomy and metadata development:
For Mike and his team, it’s about people and processes and how a company wants to govern its data and information.
There is no one answer, taxonomy and metadata is specific to your circumstance and business requirements. To answer the question about standards for taxonomy and metadata, are we there yet? Standards? No, but there are best practice guidelines specific to the design structure and term relationships and how to apply them to your SharePoint 2010 information architecture.
Happy classifying!
{ 1 trackback }