Starting with this post, we will begin a series of posts on SharePoint document management, sharing a little bit of our document management experience in overall, and some simple SharePoint tips on document automation that can improve your business performance and efficiency.
With this series of posts, we will overview the main points of building a successful document management system on SharePoint and some tricky moments you might overlook.
Introduction to SharePoint Document Management and Automation
A lot has been said about SharePoint document management and automation, and much more will be, because documents are not going anywhere, at least not in the foreseeable future, and we need to manage them. The more efficiently we do it, the better.
If you've read about SharePoint document management implementation failures, and how Microsoft recommends, to preserve environment performance, having not more than 5000 items per container in SharePoint 2010 or 2013, and only 2000 items for SharePoint 2007, you might think that SharePoint is not designed to handle big numbers of documents at all.
At EnovaPoint in 2008 we had some bad experience with a badly designed SharePoint environment for a customer with 100.000 docs/year turnaround. We had to spend one month to fix everything that was wrong, working on the folders, permissions, and workflows. Believe me, at that moment I was convinced that SharePoint is not suitable for big amounts of documents. Gladly I was wrong. In reality, SharePoint can handle huge amounts of documents, the only thing that needs to be taken care of is that you should architect it RIGHT from the very beginning.
If you want to configure your SharePoint to manage documents, deal with a big number of them, you need it to be adaptable to your company's growth. You should consider a lot of things, like a correct structure of sites, lists, and libraries, how to build your content types, the use of folders, permissions and workflows, search, retention, etc. That’s why it’s crucial to build a scalable and flexible SharePoint Document Management and Automation System. And it is not an easy task.
Planning your SharePoint Document Management
The very first thing for you to have is a clear and precise plan, where you can describe aspects related to the document management in SharePoint. The plan is essential for creating a right architecture for SharePoint document management in case you want to avoid troubles in the future.
To simplify things, I've prepared a list, like a plan, with everything necessary for a well-designed SharePoint document management system. With this post, I’ll cover the first 2 topics of the plan. The others will be covered in subsequent blog posts.
Plan for SharePoint document management
1. Analyze existing documents. Determine document types, properties;
2. Create a flexible and easily extendable Content Type structure;
3. Choose where and how to store documents in SharePoint;
4. Create fields, sites, libraries and lists. Add Content Types;
5. Plan for permissions;
6. Define and automate SharePoint document naming;
7. Unify document templates location;
8. Distribute content to smaller files;
9. SharePoint Document Automation;
10. Optimize views and libraries;
11. Implement Workflows;
12. Findability and Search;
13. Backup & Recovery;
14. Plan retention and SharePoint Content database growth;
15. Have a Migration plan.
This is not a universal plan. The plan will, of course, vary based on company maturity. However, without clearly defined points, it will be hard to create a good document and content management system on SharePoint. The series is about document management on SharePoint in general, however by saying SharePoint, I am referring to SharePoint Server 2013, at least more often.
Step 1. Analyze existing documents. Determine document types, properties
Existing documents, data & organization processes are the fuel for your project on the trip to building right document management systems using SharePoint 2013 or SharePoint 2010. By analyzing existing documents, data and processes, talking about them with people from different departments will help you build a picture of SharePoint architecture, list of required properties, libraries, SharePoint lists, content types, possible SharePoint document automation and document generation scenarios, review or approval workflows, permissions
If we look at documents and processes, for example, of Sales or HR departments in the scope of document management, we will notice that they have a lot of similar tasks related to error free document generation, easy search, data or documents aggregation, reporting, document expiration management, approval, etc.
That’s why when reviewing documents you should pay attention to:
• What documents do they use, what do they look like, what content types should you create to completely describe the documents?
• What data could be filled into documents automatically?
• Should I use that data as a document metadata?
• What data needs to be put into lists for you to benefit from it by reusing it in future documents. A good example here is companies or employees lists, which can be reused via lookups.
OK, let’s talk about document and content types. Document types are different types of documents used by an organization. Content types are SharePoint containers used for storing a collection of document properties, their ordering and document templates. Is a document type the same thing as a Content type, you may ask, pretty much yes, at least very similar.
So, should the amount of document types be equal to the amount of content types? The answer is no, in most of the cases, because it’s better to have the parent – child content type structure to ensure the scalability, flexibility and easiest management of content types in the future. However, in very small environments you may have no or only a few content types for creating documents from templates. But for better structuring of information, I recommend to use content types.
Properties. The main recommendation for creating properties arises from the need to sort or search by that data, fill data into documents, use property fields for some calculations or automation, for item description in lists, for reporting and business intelligence purposes.
Where to create property fields? I recommend to create them on a site level and add them to document libraries through content types. In the majority of cases, we create columns on site level only for document libraries, for lists we use local list columns. Think about choosing the right data type when creating property fields. Consider that each additional lookup field will slow down SharePoint list view rendering.
Create column names without spaces and then rename them after creation. This will allow you to have column names that are nice and tidy and don't have those annoying _x0020_ additions to replace spaces by SharePoint.
Step 2. Create a flexible and easily extendable Content type structure
Carefully plan the content type structure, hierarchy, and metadata before creating content types.
• If you want content types to be used on every site in your site collection, create them at the root site (home).
• To simplify management put your custom content types to new meaningful groups. For example, you can group content types by departments: _HR, _Finance, _IT, _Projects, etc.
Groups are alphabetically ordered, so I use “_” symbol in group name to ensure my custom content type groups are on the top in the Site content types list to easily find them.
Always create your custom content types derived from the standard out of the box SharePoint content types (for example, for List form types use standard “Item”, for document content types use standard “Document”). In future, this will allow you to upgrade SharePoint without losing customizations.
• The hierarchical relationship allows you to reuse the settings (fields) defined in one content type (parent) in other (child) content types. The hierarchy of content types can be extended to an infinite width and depth, but the best practice is to use 3-level parent-child hierarchy.
Parent-child content type hierarchy: a closer look considering a sales/accounting scenario:
Your sales team wants to create Quotations And Invoices.
Determine how much of same metadata needs to be captured for both types of documents (Quotations and Invoices). So we can create a “parent” content type “_Sales” (derived from SharePoint “Document” content type) that contains columns that will be shared:
You would then create separate child content types “_Quotations” and “_Invoices” inheriting these columns from the parent “_Sales. Then add unique columns to the child content types, _Quotations and _Invoices to complete collection of columns. The DueDate, for example, in case of invoices or ValidUntil in case of Quotation.
When all set with columns, create a new content type and inherit it from _Quotations or _Invoices accordingly to have a separate content type for storing only a template configuration. That will help you reuse required set of columns while being able to use different templates.
Here is how the final chain of content types looks like: Document -> _Sales (for storing major properties which fit child levels) -> _Quotations (for storing all required fields for Quotations -> Quotation Template1 (using the collection of columns from _Quotations and storing Template1 information).
Think about useful metadata and try to not insert too many columns in your content types. Avoid a lot of required fields too. Users will not be happy wasting time for filling big forms. OR, as another option, you can use our SharePoint Document Automation solution JungleDocs to fill most of the columns automatically.
I am concluding this post here, but make sure to check the 2nd part of this SharePoint Document Management series where I help you decide on using SharePoint document list or libraries to store your files and present two strategies to better organize them.