Steve,
I think the examples you give are illustrative of the point I was trying to
make. Let me see if I can get through the terminology problems to clarify
the point.
John Lovejoy's comment, to which I was reacting, was that a proper EDRMS
would group emails together with other related documents, and allow the
application of retention/disposition rules at a "file" level rather than a
"document" level. My point of view is that a "record" - the thing we
records managers devote our professional attention to - is almost always a
collection of related documents rather than just a single document.
In a paper environment this is usually called a "file", such as a "personnel
file" or a "contract file" or a "XX Subject file." Each of these would hold
a collection of documents that are related to a particular employee, a
particular contract, or a particular subject, in a "file folder". No single
document within the file gives the complete record, you have to take them
all together to know the whole story. It's in this sense that I use the
terms "file" and "record" synonymously.
In the electronic environment, standard terminology muddies the issue, in
that "file" typically refers to a single document, such as a "Word file", an
"Excel file", or an "Adobe Acrobat file." An electronic recordkeeping
system would take these and relate them together into a single "record".
For instance, the electronic record of the "Jones Contract" may consist of
the related electronic files (documents) "Jones.doc," "Jones.xls," and
"Jones.pdf." It is the "Jones Contract" to which we must apply the
retention when it closes, and the individual related documents that comprise
it must inherit that retention from the EDRMS.
A properly designed EDRMS must be able to capture emails and relate them to
a particular electronic record, just as it does other kinds of electronic or
paper documents, since so much of business is transacted via email. This
was what John Lovejoy was saying, pointing out that this often involves a
human classification determination. In my opinion, a system that manages
emails separately - outside of the context of the complete record - and
applies retentions based on some made-up criteria is not a legitimate
recordkeeping system. I hope this clarifies my comment.
Greg Schildmeyer, CRM
-----Original Message-----
From: Records Management Program [mailto:[log in to unmask]] On Behalf
Of Steve Petersen
Sent: Wednesday, March 21, 2007 7:44 AM
To: [log in to unmask]
Subject: Re: Email retention FL
Greg,
Can you give us some more detail on the Why's of retention being assigned
at the file level ? Simpler I'll agree with but essential will take some
convincing. I'm also confused when you say file or record level- I think
those can be different.
Truer words were never spoken, John. It's not just easier, but essential,
that retentions be applied at the file or record level, not an individual
document level. This point so often gets obscured in discussions of
retention, especially of emails.
Some examples I can think of are
Multiple documents that make up a record being stored in different files.
It happens in todays electronic world
Filing systems that are set-up/managed by project and or have event
triggers to start a retention clock. You could have multiple retention
periods all starting under a single trigger event,in single files.
Instances where security access is assigned to a record series instead of
the file level . This could cause an entire folder to be locked down for
restricted access when in reality only a small % of the documents are
actually affected. This is an actual example on trying to make Foreign
nationals more productive at my company.
I've struggled with this myself and trying to dump docs into defined files
is much different in the electronic vs. physical world.
Let the flogging begin
Thanks
Steve Petersen CRM
Records Manager
Rockwell Collins Inc
319.295.5244
"Bringing Order Out of Chaos"
List archives at http://lists.ufl.edu/archives/recmgmt-l.html
Contact [log in to unmask] for assistance
List archives at http://lists.ufl.edu/archives/recmgmt-l.html
Contact [log in to unmask] for assistance
|