Usually I try to use links as extra value to my posts rather than letting the post be about the link. If the linked-to website disappears then the post becomes useless. But in this case I'll make an exception as the blog entry I'm linking to discusses planned digital information obsolescence and I think the potential irony of playing with another form of information obsolescence is worth the risk.
Author Charles Stross sums up the problems (which I've been banging on about at work for at least the last six years) with the ever changing face of word processor files in his blog. He also provides his own solutions for it, which are not currently possible at the BBC where we're very closely aligned with Microsoft.
I'm not sure if it's appropriate for me to comment on our corporate ties with that (or any other) firm, so I'll refrain from editorialising. You may read into my silence whatever you chose.
Tuesday 27 January 2009
Wednesday 7 January 2009
Digital Preservation
Received a link to this through the JISC Records Management list. It questions the thinking around what should be preserved when considering digital objects. It's a question that we still need to get around to answering at the BBC, but my thinking is increasingly in line with Dr James Currall's when he talks about the importance of preserving the information but not fetishising the container. While there is a degree to which we want to look at digital objects as artefacts, given the amount of information we need to manage, I don't see that it is even remotely possible to consider all digital objects as artefacts. Rather it is better to retain enough to be able to recreate a picture of how we used information, but to the extent that we can recreate how we used every single piece of information.
Friday 2 January 2009
Building a Better Retention Schedule
We've been working with a functional retention schedule based (loosely) on the model created by the National Archive of Australia for about six years now. At the time it was created it was intended for departments to be able to use it to manage their own records by looking up the record - as they understood it - on a database. An approach which necessitated a great deal of detail going into the schedule.
The schedule was developed at the same time that we began work introducing our first electronic records management system. Unfortunately the two pieces of work were conducted largely in isolation.
Subsequent development of electronic records management has led to the development of a classification scheme that maps to the retention schedule. Unfortunately, as the retention schedule has been built around applying retention rules to record types, it would be impractical to create the number of classifications that would have to be created to make the two schemes match exactly. In the BBC we use Livelink and apply retention periods at folder levels to allow the automatic inheritance of classification/retention to items stored within the folders. Expecting staff using these folders (who are not trained in records management) to seek out and find the correct folder to place their document in would be extremely impractical if not impossible. So we compromised.
What we did instead was group as many classifications together as possible where there was a logical grouping with all the record types having the same (or similar) retention periods.
For example, on the retention schedule we might have had the following:
Meeting minutes (Archive after 3 years)
Meeting papers (Review after 3 years)
Meeting Agendas (Destroy after 3 years)
On the classification scheme this would be combined under a classification of Meeting Records and given a retention rule of Review after 3 years. The retention schedule would then be used as appraisal criteria for the minutes and agendas.
This still worked within a functional framework where we had classifications following the format of Function - Activity - Record Type/Group. So the classification would be something along the lines of Strategic Development (Function) - Meetings (Activity) - Meeting Records (Record Group).
It's still too many classifications. We've been working with this system for a couple of years now and have been struggling to educate users of the ERMS in correctly storing their documents. We've also had requests for retention rules for email systems and a proposed roll-out of Sharepoint, where the requirement is for much simpler retention rules.
So, we're now in the process of trying to roll-up the retention schedule. Rather than the rules being set at the record series level, we're looking at having our retention set at the activity level. It's something of a challenge, particularly when an activity can hold dozens of record types with widely differing retention periods. So what we're trying to do is create a structure where the standard is to apply retention at the broad level with the allowance for exceptions where legislation or business or archival requirements intervene. It's an attempt at being much more hands-off, and to a large degree putting more responsibility in the hands of the business users to make sure that they manage those exceptions properly. No telling if it's going to work, but as the present system is no longer entirely fit for purpose, we need to do something.
The schedule was developed at the same time that we began work introducing our first electronic records management system. Unfortunately the two pieces of work were conducted largely in isolation.
Subsequent development of electronic records management has led to the development of a classification scheme that maps to the retention schedule. Unfortunately, as the retention schedule has been built around applying retention rules to record types, it would be impractical to create the number of classifications that would have to be created to make the two schemes match exactly. In the BBC we use Livelink and apply retention periods at folder levels to allow the automatic inheritance of classification/retention to items stored within the folders. Expecting staff using these folders (who are not trained in records management) to seek out and find the correct folder to place their document in would be extremely impractical if not impossible. So we compromised.
What we did instead was group as many classifications together as possible where there was a logical grouping with all the record types having the same (or similar) retention periods.
For example, on the retention schedule we might have had the following:
Meeting minutes (Archive after 3 years)
Meeting papers (Review after 3 years)
Meeting Agendas (Destroy after 3 years)
On the classification scheme this would be combined under a classification of Meeting Records and given a retention rule of Review after 3 years. The retention schedule would then be used as appraisal criteria for the minutes and agendas.
This still worked within a functional framework where we had classifications following the format of Function - Activity - Record Type/Group. So the classification would be something along the lines of Strategic Development (Function) - Meetings (Activity) - Meeting Records (Record Group).
It's still too many classifications. We've been working with this system for a couple of years now and have been struggling to educate users of the ERMS in correctly storing their documents. We've also had requests for retention rules for email systems and a proposed roll-out of Sharepoint, where the requirement is for much simpler retention rules.
So, we're now in the process of trying to roll-up the retention schedule. Rather than the rules being set at the record series level, we're looking at having our retention set at the activity level. It's something of a challenge, particularly when an activity can hold dozens of record types with widely differing retention periods. So what we're trying to do is create a structure where the standard is to apply retention at the broad level with the allowance for exceptions where legislation or business or archival requirements intervene. It's an attempt at being much more hands-off, and to a large degree putting more responsibility in the hands of the business users to make sure that they manage those exceptions properly. No telling if it's going to work, but as the present system is no longer entirely fit for purpose, we need to do something.
Subscribe to:
Posts (Atom)
Posts
