Electronic Records Management

The Constant Migration Problem

2008-03-04T14:27:00.000-08:00

Suppose your organization hires someone tomorrow. You create an employee record in your ERP system for the new hire. Let's suppose that person works for you for five years. Regulations may require and common sense would dictate that your organization needs to keep that employee record for a number of years (65 years after separation from the firm seems common). With Moore's Law in full force and ensuring ongoing obsolecense of our computer systems, that record will need to be migrated from outdated (or soon to be outdated) systems, media, and file formats to whatever happens to be in fashion at the time several times throughout its life.

For instance, in the example above, a record must remain viable for 70 years. Suppose your organization determines a six-year cycle is appropriate. The record would naturally undergo 11 migrations during its life span.

This can place a tremendous burden on already strained IT budgets and resources to stay in continuous migration mode.

One Example of ERM Complexity

2008-03-03T22:18:00.000-08:00

Suppose a given report is deemed as significant and that various ERM rules regarding its handling apply. Some experts hold that the final format of the report (e.g., a PDF or Word file) is not what needs to be preserved--but rather the underlying data used to produce the report.

It is not far fetched to imagine that the report contains various kinds of data. Perhaps at the very least it contains address and financial information. In the following diagram I attempt to depict a common scenario where the address data would reside in one data source, whereas the financial data my reside in another. And in today's world of cloud computing we can no longer assume that all of our data resides safely on servers we own and maintain behind our firewall; more and more of it will be living on shared servers outside of our walls.

In such a scenario, it is plausible to have fields, records, or tables that require special ERM handling "sitting" directly next to other fields, records, or tables that do not. We will probably not have the luxury of drawing a thick line around an entire database and designating the entire thing to receive certain ERM treatment. We will likely have to be much more sophisticated.

10 Scenarios and a Nomenclature

2008-03-01T00:12:00.000-08:00

I created the following model in order to facilitate discussions around how to handle various record types:

One quickly realizes there are 10 basic scenarios. For instance, the following diagram depicts a record that is born digitally and has a digital life cycle (e.g., a contract that is created in Word and is then electronically routed, approved, signed, and stored):

The short hand I use for this scenario is "C^d:L^d" where "C" represents how the record is created (digitally^d), and "L" represents the record's life cycle (also digital^d in this example). I prefer to use superscripts for the "d" or "p" (digital or physical) designations when available. When it is not, I would write this same scenario as follows: "C[d]:L[d]".

The other nine scenarios follow logically and are depicted below in smaller, abbreviated models:

In the next post I'll explain one possible way of using these models to create an easy-to-understand rules matrix that outlines what action(s) to take with each scenario.