Following on from Part 1
Lets consider a simple example of in place v central records when it comes to aggregated content.
So imagine we have an image that will constitute a record at some point within it's lifecycle.
The sensible thing to do is create a content type for the image and define an appropriate information management policy etc.
So we are ready for the image to be published and viewed within our organisation. We may go through some approval or workflows and finally when all the business processes have been met, we declare it as a record....fine, that's the correct thing to do.
So we have a library containing our image content types and we use an image from the library in some content within our organisation - in this simple example we are using it within a publishing page layout.
So here's our image in all it's glory.
And here is our image content type in its document library.
So we now want to declare this as a record...fine.
In a central repository model we simple send to > records center and we are left with a nice link.
Great its now a record in our central repository.
And back to the home page.
Oh!!!!!
If we are using in place records management we can simple declare the record in situ.
And our image will not be removed.
Although this is a simple example it is an effective one.
Any content within your organisation is potentially a record, be it images, documents, etc etc.
As it is business content then it will probably come under the remit of some records management policy.
So when planning your records management architecture it is worth bearing in mind how you will aggregate any records-based content to other/all areas of your farm.
In place or central repository?
Plan, plan, plan !!!!!
Showing posts with label records management. Show all posts
Showing posts with label records management. Show all posts
02/05/2013
23/04/2013
SharePoint Records Repository & In Place Records Thoughts Part 1
Something I've been thinking about for a while now and finally decided to get something on record (see what I did there).
Records management in SharePoint is an emotive subject and I'm not going to cover the rights and wrongs of RM implementation.
I have had many discussions on the implementation of SharePoint records management with regards to In Place Records and a Central Repository approach, and while I agree each has it merits, one thing that many people don't consider is what actually constitutes a record and how do we manage a record once we realise that it's not just about documents.
So firstly lets identify what a record actually is......
Records Management ISO defines records as:
ICA's definition of a record as:
recorded information produced or received in the initiation, conduct or completion of an institutional or individual activity and that comprises content, context and structure sufficient to provide evidence of the activity.
In both the above definitions a record is defined as a piece of information but for some reason we all
think of a record as a document or group of documents. e.g. word, pdf, cad, excel etc etc.
This is where the SharePoint content types really do come to the fore. As we all know a content type can be any piece of information within a farm.
So it's easy...lets create a content type for each piece of information (impractical but possible).
Now this news may be an announcement content type or a custom content type, but very rarely is it a document, but it is a record.
But hey that's fine we will create a Great Corp News content type and use that as our news information container.
We'll even put our records managers hat on and give it an information policy, auditing, expiration and a workflow.
See it's dead easy given the wonderful functionality that SharePoint gives us.
Ok so now lets imagine that this piece of news is important, in fact its vital and can be classed as a vital record.
It may be a safety related piece of news or something similar which has to be managed following our formal records management process.
So lets declare it as a record, it's the sensible thing to do.
Scenario 1 - In Place Records
We can declare the news item (vital record) as a record using in place records management.
The vital record news item is now locked and cannot be edited or changed, which is absolutely correct.
Scenario 2 - Central Records Repository
Ok so lets declare this news item as a record inside our central repository
Oh wait a minute, we can only send document based records to our central repository.
OK it's not the end of the world, we can use our content type information management policy, workflow or similar to move it to the records centre.
We will have to move it and leave a link. If we copy it we will have two identical records in two different places in our farm...not good!
Gotcha....although the information management policy will let us set this rule, you cannot transfer a non document derived content type to the records centre!!!!
In conclusion
I understand the reasons that many organisations want to use a central repository for all of their formal records. However you should consider the following:
In part 2 I'll look at the technical issues that have to be overcome for central and in place records management....
Records management in SharePoint is an emotive subject and I'm not going to cover the rights and wrongs of RM implementation.
I have had many discussions on the implementation of SharePoint records management with regards to In Place Records and a Central Repository approach, and while I agree each has it merits, one thing that many people don't consider is what actually constitutes a record and how do we manage a record once we realise that it's not just about documents.
So firstly lets identify what a record actually is......
Records Management ISO defines records as:
Information created, received, and maintained as evidence and information by an organization or person, in pursuance of legal obligations or in the transaction of business.
ICA's definition of a record as:
recorded information produced or received in the initiation, conduct or completion of an institutional or individual activity and that comprises content, context and structure sufficient to provide evidence of the activity.
In both the above definitions a record is defined as a piece of information but for some reason we all
think of a record as a document or group of documents. e.g. word, pdf, cad, excel etc etc.
This is where the SharePoint content types really do come to the fore. As we all know a content type can be any piece of information within a farm.
So it's easy...lets create a content type for each piece of information (impractical but possible).
Lets take a scenario.
Great Corp have an intranet and like most intranets they have news on the homepage.Now this news may be an announcement content type or a custom content type, but very rarely is it a document, but it is a record.
But hey that's fine we will create a Great Corp News content type and use that as our news information container.
We'll even put our records managers hat on and give it an information policy, auditing, expiration and a workflow.
See it's dead easy given the wonderful functionality that SharePoint gives us.
So now we can add the news, as a content type, to our homepage.
Ok so now lets imagine that this piece of news is important, in fact its vital and can be classed as a vital record.
It may be a safety related piece of news or something similar which has to be managed following our formal records management process.
So lets declare it as a record, it's the sensible thing to do.
Scenario 1 - In Place Records
We can declare the news item (vital record) as a record using in place records management.
The vital record news item is now locked and cannot be edited or changed, which is absolutely correct.
Scenario 2 - Central Records Repository
Ok so lets declare this news item as a record inside our central repository
Oh wait a minute, we can only send document based records to our central repository.
OK it's not the end of the world, we can use our content type information management policy, workflow or similar to move it to the records centre.
We will have to move it and leave a link. If we copy it we will have two identical records in two different places in our farm...not good!
Gotcha....although the information management policy will let us set this rule, you cannot transfer a non document derived content type to the records centre!!!!
In conclusion
I understand the reasons that many organisations want to use a central repository for all of their formal records. However you should consider the following:
- Much of your content within SharePoint will be list based and not necessarily document based.
- Your information architecture policy should reflect this and you should identify the information that will constitute a record, not just the documents
- Declaration of records should take into consideration the limitations of a central repository without code and add-ons.
In part 2 I'll look at the technical issues that have to be overcome for central and in place records management....
14/11/2011
LGCS Term Store for SharePoint
As SharePoint is beginning to grab a hold within the UK public sector I thought I would make available the LGCS term store...hope it saves you time!
LGCS Term Store - download
LGCS Term Store - download
Subscribe to:
Posts (Atom)