Create a Records Management Solution in SharePoint 2010
Guest Author: Michal Pisarek
There has been a lot of talk within the SharePoint community in regards to the new Enterprise Content Management (ECM) features in SharePoint 2010.
Records Management had some weaknesses in MOSS 2007 which caused many customers reluctance in adopting the platform to truly manage content from creation through to disposition.
Fortunately in SharePoint 2010 there has been a significant investment in the Records Management aspects of the platform. Microsoft has listened to the user community and enhanced the functionality within the platform to support the creation of a full-fledged Records Management solution including:
- Support for multi-stage disposition rules
- Centralized management and syndication of Content Types
- Unique persistent document numbering across the entire lifecycle of content
- Complex routing rules to support hierarchical file plans
- Reporting across Sites and Site Collections for compliance details
- The ability to mix records and non-records within the same location
In this series of articles I am going to explain the process that we have gone through in creating a Records Management solution for clients using strictly out of the box configuration within SharePoint 2010. This series will provide an end to end overview of the kinds of decisions and considerations that we have made for our clients and will hopefully raise some questions from the user community about SharePoint and Records Management.
I also will be pretty honest in my findings! I am a true fan of SharePoint and love the new Records Management functionality but is it perfect? Of course not, however with some know how, configuration and planning you can build a robust, scalable solution that can really create value for your organization. I see SharePoint 2010 Records Management as a mid-market offering providing fantastic value while allowing an organization to manage their entire content life-cycle from a single, unified platform.
Our Goal
So before we start what are we trying to actually build? Well here is our very simplified version of our own endusersharepoint Records Management implementation:
- A Records Centre with a full hierarchical file plan with disposition rules defined at each node
- Centrally defined content types with retention policies and metadata attached
- The ability for users to manually declare items as records but also for items to be automatically declared as records if certain criteria are met
- A way to report on which content is in which stage of the disposition life-cycle.
- Unique document numbering that is persistent across the full life-cycle of the content
- The ability to declare any content as a Record, be it a document, list item or Document Set
Keep in mind that this is all out of the box configuration; there is absolutely no code at all! In some instances I have been a little creative and much more can be done if we layer custom code on top of our solution. But this is an example of how powerful configuration can be in SharePoint 2010.
Our Scenario
EUSP Catering Co. is a company that sells catering services. They contain a number of departments that use both collaboration sites to plan and coordinate events, in addition to less process driven sites such as document centers. When a new event is sold a collaboration site is created and all information is stored within the site. When items become records (such as contracts, menus, agreements and vendor receipts) they are either sent to a Records Center (in the case of financial information) or declared in place (in the case of discussions, tasks and other items).
The content goes through various retention rules dependent on the type of content. EUSP Catering Co. wants to reduce storage costs so a conscious effort is made to move content to cheaper storage after 3 years, and to destroy content after 7 years. In addition they wanted an easy way for employees to be able to declare contents as records, to be able to search for records and to ensure that no tampering of records has occurred.
Stay tuned as we begin the journey with EUSP Catering Co. to see if we can accomplish their goals and satisfy their business needs!
So where to from here? Well in the next article I will show the new features within SharePoint 2010 that will allow us to build our Records Management system including some tips on which features will provide instant benefit to any SharePoint implementation.
Guest Author: Michal Pisarek
Michal Pisarek is a solution specialist for Habañero Consulting Group, a Microsoft Gold Partner in beautiful Vancouver Canada. He has been working with SharePoint for 3 years and has a passion for finding the right balance between technology, innovation, governance and fun to meet his client’s needs.
You can find other articles by Michal on his blog SharePointAnalystHQ or follow him on Twitter (@michalpisarek)
- Create a Records Management Solution in SharePoint 2010
- SharePoint 2010 Records Management Overview
Great to see ECM covered at EUSP. Looking forward to the series – especially if it’s build around a real-life-like case study. BTW, EUSP Catering? Mark, branching out into new territories, are ya?
Actually, in a prior lifetime…
Hi Michal,
Can’t wait for your series. This is a great and powerful new feature in SP2010 and business requirements are more than real!
Greg
In any business firm record management is the most crucial. If data are store at paper there is a chance of misplacement of the data. So it is better for store at online. …….
Hi all,
Thanks for the feedback and interest in the series! I’m hoping to get the next article out latter this week so stay tuned.
Cheers!
Michal, I’ll be watching your series with great interest. We are looking to SP2010 upgrade in another year/6 months but I have a requirement right now to rebuild our hospital Policy and Procedure manual – so my challenge is how do I do that in SP2007 while optimizing the upgrade-ability so I can fully take advantage of the great options available when we get to the new platform? Any insight you might be able to share along the way would be so very much appreciated!
Hi Kerri!
I think that many of the fundamentals of a good RM solution can still be developed on 2007 and then moved to 2010.
Elements such as a corporate taxonomy, content type, metadata, creation of a file plan, associated disposition rules, and document management processes are all platform agnostic but need to be done before implementing in SP2010.
If you have the above done, then with some careful planning and using some of the new features you should be able to move to 2010 rather easily and make full use of the new tools available. But I will be sure to mention some examples along the way!
Hi Mike,
Really nice resources you are building up with your articles at http://www.sharepointanalysthq.com/
You can definitely sense your knowledge on CM in the blog design/ layout/ features themselves.
Very well done.
It is a very general question but here we go:
our company is going to use SP2010 for contracts document management (and extend it further down the road to include proposals and other legal documents).
One of the execs request it to have the documents ‘renamed’ following a specific naming convention that has been established based on the type of document within a given project (going from forms, primme agreement, contracts, schedule, Notice to Proceed doc, draft or signed record contract etc….). Very typical stuff.
Back to the ‘renaming’ part. My current idea is to start from a Record Center, using Managed MetaData to tag the document according to its type (thanks for the tip on how to display the ‘parents’ tag – still learning the SP2010 UI). The file – b/c execs ‘think’ the documents may have to be download and pulled outside of SP – has to be rename on the tagged metadata but also the project number and other things like the date.
What is the best way to handle such renaming – workflow?
Would you see any pitfalls to that scenario?
Thanks,
Greg
Yep you can use workflow, however if you don’t necessarily need to change the title of the document you can create your own field called ‘Document Title’ or something like that as a calculated field and then use a simply formula to create the string that you want from your attached metadata.
Then create a view that shows this particular field. However if you need the title field changed, and not the approach that I suggested, then yep workflow will work