<Could you elaborate a little on the differences in approach and
methodologies in applying RIM principles to electronic information?>

<... Determining a records series and its four values is different from
paper counterparts.>

Paper and other hard media can have retention value assigned one-to-one.
That is a retention for a voucher can be assigned to a paper or image of
a voucher itself.  Electronic "vouchers" are actually a compilation of
data from various tables - and the retention value must be assigned to
data within the tables, not the compiled "voucher."  It is not a simple
matter of deleting the data from the tables when the retention is
expired.  One must maintain referential integrity - i.e. when the data
is deleted it does not created gaps on in the reference functions of the
software during a data query resulting in freezing the system or
producing an endless search loop.  So deletion is based not only on
value and retention trigger, but also on inter-connectedness of the data
and the tables.  (Sounds like a new "awareness" from the 1970's).  Most
larger systems assign the inter-related data to "objects" (a customer
object, a premise object, a meter object) and the retention is then
applied to the object based on a "trigger" which is not necessarily the
same event trigger that cues retention of hard media records.  For
instance - retention of our customer billing and account information is
3 years after close of fiscal year and completion of audit in which
customer account is terminated.  For our paper records it is simple to
apply.  For the new database structure, however, we have to apply the
retention based on when the service is discontinued (the "contract" for
the service is closed upon move-out of the customer) and when the final
payment is received.  Both the "contract" and the final payment
transaction are part of other objects, which must be purged first before
the system will allow the customer account to be purged in order to
maintain the referential integrity.  All three objects are based on
multiple tables that are interconnected with each of these objects as
well as other objects.

<... Determining vital records and classifications and priorities is
applied differently than for paper and manual system counterparts.>

Again, the interconnected tables makes it difficult to apply "mission
critical" criteria one-to-one.  Where we are able to identify a vital
record in hard media format and protect it, we have to include some
non-vital data along with vital data in the electronic system.  In
addition, recovery from hard media is far more precise - we can choose
specific vital records to bring back in the prioritized order we have
pre-determined.  With the large electronic systems, we have to bring
back all tables that are interconnected in order to recover vital
records that are compiled from the tables.  One thing to remember when
recovering from backups is that it takes as long to reload data as it
did to back it up.  So if it takes 7 hours to backup a server (with a
slow tape backup system), it will take almost 7 hours to reload that
data to the server.  To expedite recovery, the larger database system is
backed up to a SAN (storage area network) rather than to tape.  A more
expensive and complex method of backup, but necessary for quick and
efficient recovery.

<... Determining electronic file "classifications" and organizing
electronic documents, files, folders, tables, databases, etc. into
efficient hierarchies requires different methodologies than paper
counterparts.>>

Again, back to the interconnected tables.  Data in a large system just
plain behaves differently than the content of hard media (and fixed
images).  The efficiency of a large database is dependent on the
interconnectedness of the data tables and the functionality configured
and programmed into the system.  No record "stands alone" so it is
difficult to "file" a record or to organize the "records" in any way.
Server folders and imaging systems and EDMS systems are closer to hard
media behavior than database systems.  These can be organized and
structured more like a paper system, although metadata (i.e. audit logs,
modification logs, transaction logs, etc.) happening behind the scenes
has to be considered.  Large database systems also have metadata issues,
but it is not as difficult to deal with as the data itself.

Ginny Jones
(Virginia A. Jones, CRM, FAI)
Records Manager
Information Technology Division
Newport News Dept. of Public Utilities
Newport News, VA
[log in to unmask]

List archives at http://lists.ufl.edu/archives/recmgmt-l.html
Contact [log in to unmask] for assistance