Records Management in the Information Age – but how do you do that? (Part II)

In our last few posts, we presented our model for the first half of the information landscape, collaborative spaces. In this post, we’re going to start to look at the other half of the information infrastructure, the “records spaces”. At a high-level, we believe this covers the split for how most information can be organized and managed. Obviously, this model will not work for everyone and we didn’t design our software to cover only this one model, but as we’ve listened to lots of customers (particularly records managers), this is the model that seems to resonate the most with large public enterprises.

Records spaces

If collaborative spaces are where knowledge workers mostly do their day-to-day work, then records spaces are where the final, official copies of information get managed by records managers for the long haul. This is a space where IT and records management have direct control over the structure, the filing, and the policies of your organizations most important and vital information. These spaces are the focal point of a records management program. Let’s look at the key characteristics of a records space:

· Records spaces are managed primarily by records managers and special, privileged users: since they aren’t generally intended for knowledge workers (outside of reference and read-only access), records managers can configure their record spaces however best aligns to their file plan, retention schedules, and compliance requirements. While the taxonomy & policies in a collaborative space need to be simple enough to be understood by knowledge workers, the records spaces can be much more rigidly structured. This is a space for long-term filing and access, not for rapid, highly collaborative work, so you should optimize its structure to best help you keep your records management program functioning smoothly.

· All of the contents in a records space are records (or metadata supporting your records): whereas a collaborative space contains drafts or work-in-progress information that mostly doesn’t become official records, records spaces are intended solely to keep store and managed records that have been declared.

· Records are immutable: they cannot be edited or modified, since they represent the official “corporate memory.” Records also need to be retained for relatively long periods of time compared to information in a collaborative space, and it’s useful to keep your records in a well-managed space that you can be sure will exist in 5, 10, or 50 years (or at least that the content will migrate appropriately as technology changes).

So what should the objectives of a records management program be for records spaces?

1) Define folder structure & metadata schema to match the file plan: the first step of managing a records space is to make it follow your file plan, both in terms of the folder structure and the metadata required for appropriately managing records of each type over the course of their retention periods.

Metadata is an especially important consideration for a records space – given the large volume of records that organizations need to retain, it’s critical that you capture as metadata the information you’ll need to manage those records over their entire retention periods.

2) Implement retention schedules that can be followed as automatically and consistently as possible: retention schedules are influenced by business needs, legal and regulatory requirements, and a host of other factors. But key to allowing a records management program to handle a large volume of records efficiently -- and to demonstrating that your program is consistently followed -- is to design a program that can be executed with as little ongoing human intervention as possible. Of course, no one would claim that records management should be a fully-automated process… human involvement is vital in many cases. However, in all situations the goal should be to automate as much of the routine work as possible, freeing up records managers to focus only on the areas where their hands-on involvement is most valuable.

3) Create appropriate “hold order” processes to respond to external events: every records management program needs a way to suspend record disposition when external events require it. However, even these hold order processes should be as automated as possible – so that the minimum amount of human effort is required to discover content responsive to that hold order, suspend its disposition, produce it for an external party if necessary, and eventually release that hold order to resume normal record disposition. (Minimizing human effort here is one of the keys to reducing your litigation & discovery costs -- remember that “$2.8 billion” figure for e-discovery services from an earlier post?)

4) An ability to audit the usage and conformance of your records and policies to your stated plans and goals. The best laid plans are useless if you don’t have a means for monitoring and reporting on where your content is filed, how often it’s being referenced, by whom, and how much of your content is “out of policy” for various reasons – you haven’t completed all of your vital records reviews, you haven’t approved the disposition for expired materials, and a report of all materials managed by active hold orders.

So with those objectives defined, we can now summarize the capabilities that are required in a records space:

· The ability to implement a record file plan & metadata schema

· A way to implement retention schedules that minimize the amount of manual effort required

· Hold orders to deal with litigations & external events (which may impact the retention of content in collaborative spaces)

· A way to generate audit trails and reports to verify that your system is functioning as expected.

· A mechanism for accepting records declared in collaborative spaces in a way that ensures that they fit into the record space’s file plan & metadata schema.

This last requirement is subtle but critical -- The records space needs to receive records from collaborative spaces, determine where in the file plan they belong (using the declaration & classification information provided), and ensure that appropriate record space metadata is collected. This allows records managers to have a rich file plan in their records space, while keeping their organization’s collaborative spaces simple enough for the knowledge workers -- and still have a successful records management program.

 

Sounds easy, right? Well, at the very least you’re going to need a powerful set of tools to do what we’ve described here. But the good news is that the 2007 release of the Microsoft Office System provides all of these capabilities. And in the next set of posts, we’ll show you how. :)

 

- Ethan Gur-esh

Program Manager

Comments

• Anonymous
  May 07, 2006
  The comment has been removed

• Anonymous
  May 08, 2006
  You state "All of the contents in a records space are records (or metadata supporting your records): whereas a collaborative space contains drafts or work-in-progress information that mostly don’t become official records, records spaces are intended solely to keep store and managed records that have been declared." I find this distinction quite rigid. Looking at Document and Records Management systems, they usually allow editing records and versions of records. Why do you decide to make this strict distinction anyway? Or: why not use a records management system with version for collaboration?
  
  - If my previous claim is correct then what you state next, "Define folder structure & metadata schema to match the file plan", will be much more difficult too. I see that defining such a structure is not the problem, working with it is.
  
  - "A mechanism for accepting records declared in collaborative spaces in a way that ensures that they fit into the record space’s file plan & metadata schema." This is indeed very important. In our organisation you have early-phase projects, as we call them. With lots of draft documents. But soon some of these drafts are frozen (with corresponds to your distinction between the collaboration and records domain) and moved (manually!) to another domain. But there is one issue here that is also important: don't loose the context! The documents that lead to a record or a managed document are usually very important to understand that document. An email about a document, for instance, gives important info that is needed to understand the attached document. Most people throw away the email, with major consequences... Most systems don't support this "saving context" either.

• Anonymous
  May 13, 2006
  @Hef:
  
  We believe that our system can handle all of the different types of classification schemes that you mention (although the decision of what type of taxonomy to use in a retention program is a subject worthy of its own discussion...)
  
  Regarding your point about interoperability with other large document and records management systems, we've made some significant investments in making sure that our products can work well with other systems. And longer-term, we are participating in standards efforts like AIIM's iECM group (http://www.aiim.org/article-pr.asp?ID=29666) to help make it easier for different document & records management to work together.
  
  - Ethan Gur-esh.

• Anonymous
  May 13, 2006
  @Samuel:
  
  Regarding your first question – you’re absolutely right that even after a document has been declared as a record, it’s important for users to be able to create new documents (or versions) that are based on the record content. The “rigid distinction” is more about what guarantee of integrity the system needs to provide – i.e. the goal is that once something is declared to be a record, an “authentic” version/copy of it must be retained somewhere where users cannot subsequently alter/modify it in any way. But that goal needs to be met in a way that doesn’t prevent/deter knowledge workers from continuing to work with information that they need.
  
  Your comment about the importance of “context” is also correct. For example, the “record” that a company may need to keep about a critical document may well include additional information beyond just the document content – such as an audit history of who contributed to or viewed it, e-mails documenting decisions that were made about the document, etc.
  
  And now that we’re about to start talking about product capabilities in this blog, I’m happy to say that our product provides capabilities to meet both of these goals – and we look forward to hearing your feedback on those features as we get into the details.
  
  - Ethan Gur-esh.

• Anonymous
  May 14, 2006
  I am concerned about your suggestion that only final pieces of work are records.
  I belive that a record should show the thinking process that contribute to a decision. This is generally illustrated in successive drafts. Therefore drafts are records

• Anonymous
  May 17, 2006
  Seems like some of the age old RM discussions are starting to rear their heads, including the classic "when is a record a record".  So long as you are building flexibility into the system as suggested to allow clients requirements to be met that should be fine.
  
  Haven'nt seen any comment yet about "what" is a record other than reference to emails etc.  Example - in the AEC world drawings are clearly key artifacts and hence records.  They also require specific handling and processing to be of any use with Engineering types.  I am sure this has been identified!

• Anonymous
  May 25, 2006
  @Kate, Aggie:
  
  You're both right that the notion of what constitues a record (different types of content, additional "context" about the etc. possibly including drafts or related files) is something that vary from one records management program to another.
  
  So flexibility to be able to support those different types of objects as records is a critical requirement for any records management system, ours included.
  
  And as we get further into the details of the records management functionality in the 2007 release, we'll definitely be making an effort to show how we've built that flexibility into our products.
  
  Ethan Gur-esh
  Program Manager

• Anonymous
  June 11, 2006
  The comment has been removed

• Anonymous
  June 19, 2006
  The comment has been removed

• Anonymous
  August 19, 2006
  The comment has been removed

• Anonymous
  August 21, 2006
  @ Cam:
  
  While other members of this community may be able to offer some insight, we (Microsoft) are definitely not the right people to be giving advice of this nature.  Determining what laws or regulations your organization needs to comply with based on the jurisdictions & industries in which you operate is a task for your company’s legal department.
  
  There are some online resources that may be of assistance when making determination, including ARMA International’s resource page (http://www.arma.org/) .
  
  - Ethan Gur-esh.

• Anonymous
  September 25, 2006
  SharePoint 2007 - General information SharePoint Server 2007 - Hidden gems Microsoft Office SharePoint

• Anonymous
  June 08, 2009
  PingBack from http://cellulitecreamsite.info/story.php?id=622

• Anonymous
  June 09, 2009
  PingBack from http://menopausereliefsite.info/story.php?id=208

• Anonymous
  June 15, 2009
  PingBack from http://unemploymentofficeresource.info/story.php?id=4148

• Anonymous
  June 18, 2009
  PingBack from http://gardendecordesign.info/story.php?id=4459