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.
Sunday, 27 April 2008
The problems with ERM
Working on a folder structure for an EDRM solution for the pensions department, two things become pretty obvious:
1. We are sorely lacking in understanding of what half the terms used by the department mean. A couple of of times I checked out Wikipedia to figure out what something meant.
2. The way the department want their folders structured does not easily work with the requirements of an EDRM - or at least the one we're using.
Here are some of the causes of these issues, as I see it:
1. Our expertise in various areas' records has been diluted as we've moved away from the local registry system of records management to a more diffuse structure. Admittedly we've never really done anything with pensions, so we'd have had trouble with them anyway, but with not having a local records manager who is also familiar with the work of the specific department, we're not going to necessarily have the expertise to be able to understand the records. Ideally we need to be able to work at length with the people from the department in question, but that's often impractical (particularly when we're based in London and Pensions are in Cardiff).
2. We didn't engage early enough with electronic file creation. We've been using computers to generate documents since I started working at the BBC 18 years ago (admittedly we only had two in an office of 10 when I started, but that changed in less than a couple of years), but we've only been managing any of those records in their native formats since 2002 - so it took us 12 years to try to address the problem.
3. As the record creators have been left alone to structure their own data as they see fit with very little guidance from us, they've got into the habit of doing that in a certain way - which does not necessarily fit the functional classification model that we've been trying to use.
4. We're still trying to follow a one-size fits all approach to records management - where what we probably need are a host of different solutions. We are well aware that there's a difference between paper and electronic records and how they're managed, but the place in our policies and strategies where we acknowledge that might not be at a high enough level. I think we may also run into trouble as we try and merge all the BBC's different media types into one policy framework if we're not careful.
Steve Bailey's keynote speech at the RMS conference this month covered off on some of the issues surrounding these problems - and throughout the conference he was generally looking for solutions that weren't just an electronic version of the hard-copy file systems. I think that's what we need to be doing as well.
1. We are sorely lacking in understanding of what half the terms used by the department mean. A couple of of times I checked out Wikipedia to figure out what something meant.
2. The way the department want their folders structured does not easily work with the requirements of an EDRM - or at least the one we're using.
Here are some of the causes of these issues, as I see it:
1. Our expertise in various areas' records has been diluted as we've moved away from the local registry system of records management to a more diffuse structure. Admittedly we've never really done anything with pensions, so we'd have had trouble with them anyway, but with not having a local records manager who is also familiar with the work of the specific department, we're not going to necessarily have the expertise to be able to understand the records. Ideally we need to be able to work at length with the people from the department in question, but that's often impractical (particularly when we're based in London and Pensions are in Cardiff).
2. We didn't engage early enough with electronic file creation. We've been using computers to generate documents since I started working at the BBC 18 years ago (admittedly we only had two in an office of 10 when I started, but that changed in less than a couple of years), but we've only been managing any of those records in their native formats since 2002 - so it took us 12 years to try to address the problem.
3. As the record creators have been left alone to structure their own data as they see fit with very little guidance from us, they've got into the habit of doing that in a certain way - which does not necessarily fit the functional classification model that we've been trying to use.
4. We're still trying to follow a one-size fits all approach to records management - where what we probably need are a host of different solutions. We are well aware that there's a difference between paper and electronic records and how they're managed, but the place in our policies and strategies where we acknowledge that might not be at a high enough level. I think we may also run into trouble as we try and merge all the BBC's different media types into one policy framework if we're not careful.
Steve Bailey's keynote speech at the RMS conference this month covered off on some of the issues surrounding these problems - and throughout the conference he was generally looking for solutions that weren't just an electronic version of the hard-copy file systems. I think that's what we need to be doing as well.
Wednesday, 23 April 2008
Reviewing blogs
The BBC's been fiddling about with social software for a few years now, both internally and externally. This has largely been ignored in terms of information management, although we have had a bit of a look in terms of information policy compliance and in the past I've written a couple of short briefing documents on the issues raised by internal blogs and wikis.
More recently, due to changes in the software we're using to power these, a lot of the old blogs and wikis may have to bite the dust, so we've been taking a look at them to see (1) if there's anything worth saving for archival reasons (2) if there are any business/compliance reasons to keep anything around and (3) to draw up some guidelines on the future management of them. It's largely been a process of feel it and see as we've been trying to figure out how to manage this process. Today we came up with our first stab at some appraisal criteria for the blogs, which falls somewhere along the following lines:
1. It must have content. It probably shouldn't be surprising that there are blogs to which the creator never returned after asking them to be set up. That and those that consist of a few test posts and nothing else. Anyway, this is a fairly simple method of quickly narrowing the field of material to be reviewed.
2. The type of blog. We've managed to categorise most of the blogs into a few different types and assign values to each. These largely fall into the following:
4. Creator. Judged on the significance of the person/contributing team to the BBC. Senior Executives will score high here, but in terms of appraisal weight, it's only of tertiary significance.
5. Number of links. The higher the number of links, the less interesting the blog becomes. Until we find a way to capture the content of items linked to from a blog, the meaning of that link disappears the moment the information at the other end disappears. The best use of links tends to be when it provides supplementary information to the blog that when lost will not effect the reader's comprehension of the blog. Which is something I'm going to aim for with this blog.
More recently, due to changes in the software we're using to power these, a lot of the old blogs and wikis may have to bite the dust, so we've been taking a look at them to see (1) if there's anything worth saving for archival reasons (2) if there are any business/compliance reasons to keep anything around and (3) to draw up some guidelines on the future management of them. It's largely been a process of feel it and see as we've been trying to figure out how to manage this process. Today we came up with our first stab at some appraisal criteria for the blogs, which falls somewhere along the following lines:
1. It must have content. It probably shouldn't be surprising that there are blogs to which the creator never returned after asking them to be set up. That and those that consist of a few test posts and nothing else. Anyway, this is a fairly simple method of quickly narrowing the field of material to be reviewed.
2. The type of blog. We've managed to categorise most of the blogs into a few different types and assign values to each. These largely fall into the following:
- Personal blogs - no value. These are the blogs that are about people's general reflections on life, or what they watched on TV the night before. They might be fine as social documents (if written well), but they have no worth to the BBC in business or archival terms. If you find it a little odd that the BBC provides personal blog spaces within the corporation's firewall you'll have to ask Euan Semple, former knowledge manager at the BBC, about it.
- Work journals - medium-high value. Some good material here at times, at least in terms of recording information about the working lives of the BBC staff, which must be of some use to a social/media historian - at least if the content is any good.
- Work issues - low-medium value. Largely collections of links (some reviews) relating to the issues and technologies around people's jobs.
- Communications - no/low value. A means of disseminating information among staff. Tends to be very ephemeral and frankly if the communication was that important, it's more likely to have gone out on an email rather than a blog.
- Technical logs - temporary business value. These contain lists of things like service outages, the nightly programme schedules. Of use in the short term, but unless you like dull technical lists, no one's going to want to keep it around for long.
- Media comment - medium value. Someone's thoughts on what's going on the television/radio/online/news world. Can provide an interesting collection of observations, largely depending on who's doing the observing.
- Test blogs - no value. Largely goes back to the 'No Content' criteria, although some test blogs clearly have a lot of content - it's just all meaningless for anything except the original test.
- Advice/Information - low/medium value. Mostly a temporary business need as the content of these blogs seems to date quite quickly. And experience suggests there's no real value in preserving it for historical purposes.
4. Creator. Judged on the significance of the person/contributing team to the BBC. Senior Executives will score high here, but in terms of appraisal weight, it's only of tertiary significance.
5. Number of links. The higher the number of links, the less interesting the blog becomes. Until we find a way to capture the content of items linked to from a blog, the meaning of that link disappears the moment the information at the other end disappears. The best use of links tends to be when it provides supplementary information to the blog that when lost will not effect the reader's comprehension of the blog. Which is something I'm going to aim for with this blog.
Tuesday, 22 April 2008
Why this blog?
You can blame the RMS Conference for this blog. Between Keith Gregory's discussion on social computing tools and Steve Bailey's enthusiasm for the whole thing, I decided that what the world needs right now is another records management-themed blog.
Actually what I came away from the conference with was a sense that if the whole wonderful world of Web 2.0 is to be tackled by records managers then we've got to get our sleeves rolled up and get stuck in with the whole thing ourselves. We all know how a regular document works, but dynamic content is a whole other matter. We're in the middle of looking at some of these issues for work and there are a whole load of issues that we've never had to deal with when managing traditional documents.
So this is my attempt to play about with the blog format. Although I already have another two personal ones, this is my first go at creating something that might have some value - even if it's just another voice joining the conversation.
Actually what I came away from the conference with was a sense that if the whole wonderful world of Web 2.0 is to be tackled by records managers then we've got to get our sleeves rolled up and get stuck in with the whole thing ourselves. We all know how a regular document works, but dynamic content is a whole other matter. We're in the middle of looking at some of these issues for work and there are a whole load of issues that we've never had to deal with when managing traditional documents.
So this is my attempt to play about with the blog format. Although I already have another two personal ones, this is my first go at creating something that might have some value - even if it's just another voice joining the conversation.
Subscribe to:
Posts (Atom)
Posts
