Skip navigation

Monthly Archives: July 2010

It’s been months since I last posted. Whoops. Lots of personal change for me. Some of it good, some of it not-so-good. Hunter Thompson once said that the best way to control your environment was to get off the defensive. Fair enough, Doc. So here I am, my hands back on the throttle.

This latest post is about something that I am seeing quite often these days. Confusion. More specifically, the confusion over what content management is and what records management is and how they relate (and how they don’t). I have seen it many times among many of my colleagues, customers and prospects. The range on the level of confusion is fairly broad.

Records Management is a specialized discipline with its own methods, vocabulary, best practices, etc. Records Management is not a technology itself but Records Managers seek to make use of technology to better perform and automate their lower-value tasks. The life of an RM can be quite challenging as they live and breathe through a lot of detail. Many of the RMs I’ve met have no more then a spreadsheet and email to deal with their job. Ouch!

You can imagine then that an industry of Records Management solutions must have emerged to help with the pain. Your imagination is very astute. Indeed many RM solutions from a variety of vendors have happened on the scene. These are quite a necessity to help Record Management practitioners keep up with the large and accelerating volumes that organizations are accumulating. For a definition of Records Management there is a wikipedia entry that goes into further details here.

It turns out that a number of Records Management functions are uncannily similar to Content Management functions. For example, content classification and records classification are essentially the same. Classification in this sense refers to the act of evaluating a document and understanding its purpose (e.g. invoice, contract, and so on). In both cases the content is reviewed, a decision made and the document is “classed”. The only real difference is that the content taxonomy and record taxonomy are separate and unique. An invoice may be received, classified and placed into a content management repository while it undergoes processing and approval. Simultaneously a record manager may also assign this invoice a category in the record catalogue (called a “file plan” by Record Managers).

Consumers of the content and records managers both need to understand the nature of the content but still view it through different lenses. The subtle difference is that content consumers (for example an Accounts Payable clerk) need to work directly with the data to complete a process (in the case of AP, that might be approval and payment of an invoice). The record manager, on the other hand wants to understand the content’s retention schedule and where it fits in the taxonomy. The content classification is important because it indicates how the content is to be consumed, the record classification determines the lifespan and archival requirements. With that in mind, it is important to understand here that a document can have both a content classification and a record classification.

To further this point we can think of content as having two lifecycles: a Content Lifecycle and a Record Lifecycle. The first deals with the content as it is being authored, edited, processed, approved and so on. The second deals with the content as it is being archived, retrieved and ultimately destroyed. These lifecycles may not necessarily be formalized either. As everyday creators and hoarders of our own content we all take part in this cycle. As I write, edit and publish this blog post the content is in an “authoring” stage. After I publish the post it then goes into an “archival” phase where people read it (I hope) and eventually I may even take it off-line or even delete it. These two phases informally represent the cycles of content and record management. While I have not officially declared this post a “record” in the formal sense I am treating it like one. Every piece of content–whether it is a tax document, email, MP3 file, junk mail or picture your 4-year-old drew–follows this same pattern. Every piece of content has its own lifecycle.

In large organizations with (hopefully) structured and formal processes every record should have a point in time where it is destroyed. That point differs between record types. It really depends on the type of information and the surrounding legalities. There are some records, such as a bank’s financial documents, which must be kept for at least seven years. Documents with longer retention periods, such as a birth certificate, may need to be kept for hundreds of years. The period of retention assigned to a record is called a retention schedule. Retention schedules are given to record categories and record categories are organized into a body of work called a File Plan. Up to this point I have been referring to the “file plan” as a “record management taxonomy”. While this might seem like an abstract concept it should be noted that every one of us deals with a formal record management system quite often.

Your public library is, in fact, a record management system. Really. By the time the books reach the shelves they would have completed their “content authoring lifecycle”. The file plan in your neighbourhood library is nothing more then the Dewey Decimal system. Each subject catagory in Dewey Decimal is, in fact, a record category (with many sub-categories). Of course, your friendly librarians are the record managers. I can’t help but devilishly note here that the very first Record Managment systems were the writing repositories founded in ancient Mesopotamia. Unfortunately the scribes and scholars there didn’t have much in the way of spreadsheets to assist them.

Seriously though, it should not be too surprising that librarians and museum staff take similar training as corporate records managers. Just take a look at the programs offered at the University of Toronto’s Information School.

Creation of a File Plan, developing retention schedules and enforcing this behaviour is the mandate of every record management team. However this is not always well adopted by many organizations. It is a heavy task to review every type of content and most record management teams only have the bandwidth to handle a small subset of their organization’s content. For example, a bank may have thousands of different types of documents but may only place the loan and investment documents under record management. These types of documents represent some of the highest volumes in the bank and it is not only vital to the bank and its customers that these follow a formal retention schedule but there are also legal compliance issues at stake. The legalities vary from country to country and from sector to sector.

Even with those documents under record management there may not always be the cultural will or even ability to destroy the records when it is time to do so. Large organizations such as banks or insurance companies have billions of pages of records in both paper and electronic format at any given time. A well-organized system is most onerous to maintain, review and destroy records when the retention schedule calls for it. As a former manager of mine used to epouse about the ill-famed Enron, “They got burned not for destroying documents they shouldn’t have been destroying but for destroying documents that were already supposed to have been destroyed.” Whoops.

Records Management systems are brought into the picture to automate the day-to-day opertions of records that were born digital (e.g. Microsoft Word docs), electronic (scanned) images and physical records (e.g. paper docs, photos, etc). Below is a list of various record management system capabilities:

Create and maintain record file plans – a decent RM system should be able to handle both electronic AND physical records in the same file plan. It should also support creation of multiple file plans in the same system.

Automation of common records management tasks – for example auto destruction and vital and periodic record review

Compliance features – legal holds, granular auditing and reporting capabilities
Support record searching and retrieval

eDiscovery Support – Search and retrieval capabilities which give RMs, Compliance and Legal team members the ability to query, locate and view records. Furthermore there should be an ability to show what queries were made and an audit trail of who has made them.

If you noticed I did not mention anywhere above that the record management system would actually STORE the content. That is not the job of a record management system. This might be easier to grasp for physical records where they would be tracked in the RM system but physically stored in a shelf, warehouse or a 3rd-party storage company such as Iron Mountain.

Perhaps now you can start to see where the confusion begins. Here we have two related systems that serve different masters. I took pains to present RM and its various use cases in order to be clear what an RM system is.

Hopefully you are able to understand that ECM and RM are both symbiotic and disparate. That they both flow together and yet require a difference in their practices. Clear as mud, right? The confusion is real and understandable. OK so now I will stop here as this post has gone on too long. 🙂 In my next post (Part 2 of this topic) I will go through the top things that people get confused over between RM and ECM.