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.

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:

• 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.
  

3. Usage Indicators. We use a scale of density/time - so anything with high density over a long period of time gets extra points, with the opposite end of the scale obviously being low density over a short period of time.

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.

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.