SharePoint Document Management: Determining Your Metadata
Metadata is the terminology used to describe information and data about other data. It is a term that is known by most but can be misunderstood.
An example I like to work with when discussing SharePoint Metadata with my clients is that of produce purchased in the supermarkets – usually Heinz Baked Beans (other brands of are available!). When purchasing this item I understand a lot about it without needing to open the can; I know the brand name, the breakdown of ingredients and the calorific values. If I am happy with the data associated to the product then I will purchase it and continue my trip, otherwise, I will search elsewhere. I am also able to locate these items easily, as they are stored with products of a similar type, and there are numerous signs pointing me in the right direction and indicating the aisle in which they can be searched for.
Metadata in Document Management is essentially the same user journey, although instead of finding my weekly shopping I am locating specific documentation. I want to be able to search for my document in the correct area, where it is stored with similar materials e.g. Contracts or Invoices (this is my shopping aisle). I then want to be able to determine if the content of the documents is likely to be what I am looking for without having to read each and every result, using Metadata (my ingredients) I can quickly tell whether a document is a Spanish Contract or an English Invoice – selecting the one that is most appropriate for me.
Continued in this blog post, I will be providing an overview of the different sorts of metadata to think about when setting up your Document Management System within SharePoint and Office 365, this is aimed to cover what to think about and not how to setup;
All file shares are setup in a standard way through the use of folders and sub-folders (some more organised than others!) which assist users in locating a document or understanding where they need to save their materials. Every user has already provided a document with some Metadata when doing this, even if they don’t realise they have done it. Why did you decide to create a folder named Supplier Audits, and then put a bunch of sub-folders within it; each titled with the Supplier Name? the answer is easy, you have done this as it feels like the most logical approach to store and find data. This approach is essentially ingrained in our everyday working life.
Moving onto SharePoint your structure may change slightly or even dramatically, however, you will still have to define where documents live. SharePoint is made up of a number of Sites and Document Libraries in the first instance, so these will need to be built. Following this, you may still use some folders and sub-folders (less as the documents should already be structured in an easier way). All these decisions can determine metadata for easier search.
For example; You may have a SharePoint Site named HUMAN RESOURCES in which there is a Document Library named POLICIES. Already you have a couple of pieces of metadata that can be used – you just need to set up the columns and default values to ensure your documents remain tagged. PowerShell can also be used to programmatically tag documents based on where they live within SharePoint, but do get in touch if you wish to explore that further.
This is your high-level metadata, that is determined to be applicable to every single document that is maintained within an organisation. This is a very important set of metadata as it allows for structure to be determined for all documents, and also ensures that all documents have some form of tagging and searching capabilities provided (pending mandatory fields are used, and that your users are trained effectively).
If releasing your SharePoint Document Management System in a phased approach then the use of Global Metadata may be enough to get your first phase rolled out.
As an example; all documents are written in a specific LANGUAGE and they are all of a specific DOCUMENT TYPE, along with that you are already provided metadata by SharePoint so that you know when a document was CREATED and who it was CREATED BY, as well as, knowing who it was last MODIFIED by and what the LAST MODIFIED DATE was. As you can see, there is a variety of Metadata that can be used for every document across the organisation, whether in the thousands or millions.
The above example contains metadata that is always associated with any document in any organisation, but you may also have your own e.g. the BUSINESS SECTOR that the document is generated for.
Taking the level of Metadata one step further means that engaging with the individual Departments and Functions within the organisation is necessary, usually through a defined set of Document Management Champions.
This engagement can allow you to determine any specific tags that will assist the department in sorting, filtering and searching through their documentation and data – as well as, assisting any alternate department in locating materials also.
As an example, the Human Resources department may wish to record the EMPLOYEE NAME and EMPLOYEE ID against a number of their personnel documents, however, this cannot be global as there would be no need to have this metadata associated to a Financial Document like an invoice.
Inheriting from the Global Metadata we are beginning to build up an extended user journey to help wade through the large amount of documents and data that is usually kept. A user at this stage can now begin to search for a document that is a letter written in English, and then if any HR documentation is located it can be narrowed down further by defining the employee this letter is related to.
During SharePoint Search the refiners (metadata), which allow you to drill into search results, will only appear if there is a result that references them, therefore, if I would not see EMPLOYEE NAMES or EMPLOYEE IDS if 1) my result set did not include any documents that referenced these or 2) I cannot see these items as I do not have permissions to the documents.
Document Type Specific Metadata
Finally, there are a number of different types of document that may be uploaded into SharePoint and on occasions they warrant their own unique set of metadata, inheriting from all other sources that have been discussed thus far.
As an example, I may have a library that contains a bunch of Audit Reports, but it would be really useful to view other data about these, such as; the NUMBER OF NON-CONFORMANCES, the NUMBER OF OBSERVATIONS, the relevant EXTERNAL AGENCY who completed the audit, the AUDITOR name and the DATE OF AUDIT.
As you can see the above metadata fields drill down into the specifics of one type of document. Once again I am not going to need these at a Global level as they would be irrelevant if uploading a contract, and I am not going to need them at a departmental level as QHSE (Quality, Health & Safety & the Environment) are not going to need these tags against every document they own, only the ones related to an Audit. They may even introduce separate tags of External Audits versus Internal Audits, providing an extreme level of control.
Hopefully, you now have a better understanding of what Metadata is, what it means to an organisation, how you can determine the types of metadata you wish to use to assist in building a SharePoint Document Management System and improve business efficiency.
To ensure this is successful you need to spend time and resource to get it setup correctly, although it can always be added to in the future so phased approaches work fine. You need to engage with your users, and ensure that the system meets their requirements. This is assisted with a core communications plan and a defined set of workshops and training.
A final thought is that you need to ensure that the results are measurable and objective based. It is easy to think that minimal metadata is required (as the document management system has always been ok) or that you need loads of metadata (that may become a burden to users and administrators) – therefore, ensure you have a goal of what you want to achieve and that you continue to review this against your Key Performance Indicators (KPIs) on a scheduled basis.
Do get in touch if you wish to learn more about SharePoint, Document Management Systems, Metadata and Intranets. There are also a few more blog posts related to Document Management within SharePoint in our news section – do check them out!
This blog post was written by Steve GlassPool, our Senior SharePoint Consultant.