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 (16)
  1. Hef says:

    "file plan" – if by this you mean a taxonomy, this is one of the interesting areas in developing records management systems – and by interesting I mean not easy, and requiring a large training component for users.  Then there is the choice between functional, subject and aspect based classification schemes – will the tools handle all of them?

    I guess the other question I have is how will this all fit in to an organisation that already has one of the large electronic document and records management systems?  Is anyone acting to create standard schema such as those proposed by xml.org in other fields?

  2. Samuel says:

    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.

  3. @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.

  4. @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.

  5. Kate says:

    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

  6. Aggie says:

    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!

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

  8. Martin says:

    Hi,

    just been recommended to your site.

    I get the impression that most people who have commented are from the USA? Just to say that in the UK, public organisations are covered by the Public Records Act which defines what they must do to comply and keep information ‘For the Record’. This covers Government Deaprtments and Agencies (Central Government) as well as Local Government.

    key to all this is defining your Records Management (RM) policy which outlines what is a record. This could include keeping creating records at specific stages in the development of   …… well, whatever it is that you do.

    Records are NEVER changed and any system that allows this is really going to cause you problems. However, it should allow you to copy a record, then amend this and save it as a new document or record.

    I’ll look forward to future discussions on RM.

    Martin

  9. I am glad Martin, Kate and Aggie are reinforcing the issue I raised earlier.

    The team should check out the UK Public Records Act, 1958.

    I strongly suspect the DIRKS system has its origins in guidance issued by the UK Dominions Office in the 1930’s but many current and former UK Commonwealth countries have legislation that reflects the concept that a record does not need declaring to be a public record.  It is a record simply because it exists.  It may not worth keeping for very long, e.g. most Post-It notes, but at times even a blank sticky patch stuck to a particular page can have long-term significance.

  10. Cam says:

    Can you please advise if and what laws or regulations govern the private sector in the UK in relation to records management?

  11. @ 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.

  12. Raul Ribeiro says:

    SharePoint 2007 – General information SharePoint Server 2007 – Hidden gems Microsoft Office SharePoint

Comments are closed.

Skip to main content